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(g) Public key/signature cryptosystem with enhanced digital signature certiflcatlon. 

® A public key cryptographic system is disclosed with enhanced digital signature certification which authen- 
ttites the identity of the public key holder. A hierarchy of nested certifications and signa^res are employed 
which indicate the authority and responsibility levels of the individual whose signature .s bemg certified. The 
^sent invention enhances the capabilities of public key cryptography so that it may be ^"^P^yj^J^J^J^^^J 
variety of business transactions, even those where two parties may be virtually unknown to each otiier. Counter- 
staSre and joint-signature requirements are referenced in each digital certification to permit business 
SnstS,,^ to Ske pface eiectronicaliy. which heretofore often only would take place after^ '^^^ /"^ 
physical!; winds his way through a corporate bureaucracy. The certifier in constructir^ a ^^^mcate generates a 
special message tiiat includes fields identifying ttie public key which is being certified- '^^"r^^^fjll 
certifiee. in addition, the certificate constructed by ttie certifier includes the authority which .s being g^ted 
Sd!^g infom,atlon which reflects issues of concern to ttie certifier such as. for example the '^°!'^^}^"^*'^[ 
Ue^rti-fiee and the level of tmst which is granted to the certifiee. The certificate may also specify cosignature 
requirements which are being imposed upon ttie certifiee. 
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PUBLIC KEY/SIGNATURE CRYPTOSYSTEM WITH ENHANCED DIGITAL SIGNATURE CERTIRCATION 

RELD OF THE INVENTION 



This invention relates to a cryptographic communications system and method. More particularly, the 
5 Invention relates to a public key or signature cryptosystem having improved digital signature certification for 
indicating the identity, authority and responsibility levels associated with at least the sender of a digital 
message. 

70 BACKGROUND AND SUMMARY OF THE INVENTION 



The rapid growth of electronic mail systems, electronic funds transfer systems and the like has 
increased concerns over the security of the data transferred over unsecured communication channels. 
15 Cryptographic systems are widely used to insure the privacy and authenticity of messages communicated 
over such insecure channels. 

In a conventional cryptographic system, a method of encryption is utilized to transform a plain text 
message into a message which is unintelligible* Thereafter, a method of decryption is utilized for decoding 
the encrypted message to restore the message to its original form. 
20 Conventional crypotographic signature and authentication systems typically utilize a "one way" hashing 
function to transform the plain text message into a form which is unintelligible. A ''hashing" function as used 
herein is a function which can be applied to an aggregation of data to create a smaller, more easily 
processed aggregation of datcu 

An important characteristic of the hashing function is that it be a "one-way" function. A hash Is a "one- 
•25* way" function, if it is far more difficult to compute the inverse of the hashing function than it is to compute 
the function. For all practical purposes, the value obtained from applying the hashing function to the original 
aggregation of data is an unforgeable unique fingerprint of the original data. If the original data is changed 
in any manner, the hash of such modified data will likewise be different 

In conventional cryptographic systems, binary coded information is encrypted into an unintelligible form 
00 called cipher and decrypted back into its original form utilizing an algorithm which sequences through 
encipher and decipher operations utilizing a binary code called a key. For example, the National Bureau of 
Standards In 1977 approved a block cipher algorithm refenred as the Data Encryption Standard (DES). Data 
Encryption Standard, FIPS PUB 46. National Bureau of Standards, January 15. 1977. 

In DES. binary coded data is cryptographically protected using the DES algorithm in conjunction with a 
35 key. Each member of a group of authorized users of encrypted computer data must have the key that was 
used to encipher the data in order to use it. This key held by each member in common is used to decipher 
the data received in cipher form from other members of the group. 

The key chosen for use in a particular application makes the results of encrypting data using the DES 
algorithm unique. Selection of a different key causes the cipher that is produced for a given set of inputs to 
40 be different. Unauthorized recipients of the cipher text who know the DES algorithm, but who do not have 
the secret key, cannot derive the original data algorithmically. 

Thus, the cryptographic security of the data depends on the security provided for tiie key used to 
encipher and decipher the data. As in most conventional cryptographic systems the ultimate security of the 
DES system critically depends on maintaining the secrecy of the cryptographic key. Keys defined by the 
45 DES system include sixty-four binary digits of which fifty-six are used directly by the DES algorithm as the 
significant digits of the key and eight bits are used for enror detection. 

In such conventional cryptographic systems, some secure method must be utilized to distribute a secret 
key to the message sender and receiver. Thus, one of the major difficulties with existing cryptographic 
systems is the need for the sender and receiver to exchange a single key in such a manner that an 
50 unauthorized party does not have access to the key. 

The exchange of such a key is frequently done by sending tine key. prior to a message exchange, via. 
for example, a private courier or registered mail. While providing the necessary security such key 
distribution techniques are usually slow and expensive. If the need for the sender and receiver is only to 
have one private message exchange, such an exchange could be accomplished by private courier or 
registered mail, thereby rendering the cryptographic communication unnecessary. Moreover, if the need to 
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communicate privately is urgent the time required to distribute the private key causes an unacceptable 
delav 

Public key cryptographic systems solve many of the key distribution problems associated with 
conventional cryptographic systems. In public key cryptographic systems the encrypting and decrypting 
processes are decoupled In such a manner that the encrypting process key is separate and distinct from 
ttie decrypting process key. Thus, for each encryption key there is a corresponding decryption key which is 
not the same as the encryption key. Even with knowledge of the encryption key. it is not feasible to 

compute the decryption key. . . 

With a public key system. It is possible to communicate privately without transmitting any secret keys. 
The public key system does require that an encryption/decryption key pair be generated. The encryption 
keys for all users may be distributed or published and anyone desiring to communicate simply encrypts his 
or her message under the destination user's public key. . . ^ ... ^ ■« -4 

Only the destination user, who retains the secret decrypting key. is able to decipher the transmitted 
message. Revealing the encryption key discloses nothing useful about the decrypting key. i.e.. only persons 
having knowledge of the decrypting can decrypt the message. The RSA cryptographic system which is 
disclosed in U.S. Patent No. 4.405.829 issued to Rivest et al discloses an exemplary methodology for a 
practical implementation of a public key cryptographic system. ^ , „. 

A major problem in public key and other cryptographic systems is the need to confimi that the sender 
of a received message is actually the person named in the message. An authenticating technique known 
utilizing "digital signatures" allows a user to emptoy his secret key to "sign a message" which the receiving 
party or a third party can validate using the originator's public key. See for example U.S. Patent No. 

^'""a'^w who has filed a public key in a publicly accessible file can digitally sign a message by 
decrypting the message or a hash of it with the user's private key before transmitttng the message 
Recipients of the message can verify the message or signature by encrypting it with the sender s public 
encryption key. Thus, the digital signature process is essentially the reverse of tt^e typi^ '^'".'^S^ 
process in that the message is first decrypted and then encrypted. Anyone who has tlie users pubic 
encryption key can read the message or signature, but only the sender having the secret decryption could 
have created the message or signature. 

Serious problems still persist in public key cryptosystems of assuring that a speafied public key is that 
actually create by the specified individual One known technique for addressing this problem is to rely on 
some mjsted authority. e.g.. a governmental agency, to insure that each public key is associated with, the 
person who claiming to tie the true author. a 

The trusted authority creates a digital message which contains the claimanfs public key and the name 
of the claimant (which is accurate to the authority's satisfaction) and a representative of the authority signs 
the digital message with the authority's own digital signature. This digital message, often known as a 
certlficSte. is sent along with the user of the claimant's own digital signature. Any recipient f «^lamant s 
message can trust the signature, provided thai the recipient recognizes the authorrty's public key (which 
enables verification of the authority's signature) and to the extent that the recipient »*^«^"^f "^"^^^ . 

Prior to the present invention, the transmitted certincate failed to provide any indication of the degree of 
tnist or the level of responsibility with which the sender of the message should be empowered. Instead, the 
certification merely indicates that the identified trusted authority recognized the senders public key as 

"^'"^Se p,!Slic te^y'Sem is designed to operate such that the public keys of various use^ ^™ 
to make private communications easier to accomplish. However, as the number of parties who desire to use 
the public key system expands, the number of published keys will soon grow to a size ^^^ere the issuing 
authority of the public keys can not reasonably insure that the parties whose public keys are published are 
in fact, the people who they.are claiming to be. Thus, a party may provide a public key to be -"f "^jlned .n 
the public directory under the name of the chalmian of a major corporation, e.g.. for example. Genera^ 
Motors Corporation. Such an individuaJ may then be in a position to receive private messages directed to 
the chainnii of General Motors or to create signatures which ostensibly belong to the impersonated 

"^^'Th^ are also technotogies for producing digital signatures which may not require full public key 
capabillty.including.for example, the Rat-Shamir algorithm. Any digital signatore methodology may be 
employed to implement the digital signatures referenced herein. Any reference to public key ^Pt^fV^^^'^f 
should also be construed to reflect signature systems. Any reference to public key decryption should be 
taken as a generalized reference to signature creation and any reference to encryption should be taken as a 
reference to signature verification. 
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The present invention addresses such problems with the public key or signature cryptographic system 
relating to authenticating the identity of the public key holder by expanding the capability of digital signature 
certification. In this regard, a certification methodology is utilized which employs multiple level certification 
while at the same time indicating the authority and responsibility levels of the individual whose signature is 
6 being certified as is explained in detail below. 

The present invention enhances the capabilities of public key cryptography so that it may be employed 
in a wider variety of business transactions, even those where two parties may be virtually unknown to each 
other. 

The digital signature certification method and apparatus of the present invention provides for a 
70 hierarchy of certifications and signatures. It also ailows for co-signature requirements. In this regard, 
counter-signature and joint-signature requirements are referenced in each digital certification to permit 
business transactions to take place electronically, which heretofore often only would take place after at least 
one party physically winds his way through a corporate bureaucracy. 

In the present invenfion, a digital signature is certified in a way which indicates the authority the has 
15 been granted to the party being certified the certifiee). The certifier in constructing a certificate generates a 
specialmessage that includes fields identifying the public key which is being certified, and the name of the 
certifiee. In addition, the certificate constaicted by the certifier includes the authority which is being granted 
and limitations and safeguards which are imposed including information which reflects issues of concern to 
the certifier such as, for example, the monetary limit for the certifiee and the level of trust which is granted 
20 to the certifiee. The certificate may also specifyco-signature requirements as being imposed upon the 
certifiee 

The present invention further provides for certifying digital signatures such that requirement for furtiier 
joint certifying signatures is made apparent to any receiver of a digital message. The requirement for joint 
signatures is especially useful in transactions where money is to be transferred or authorized to be 

25 released. To accomplish this end. the certificate of the present invention is constructed to reflect (in addition 
to the public key and the name of the certifiee and other fields) the number of joint signatures required and 
an indication as to the identity of qualifying joint signers. Thus, an explicit list of each of the other public 
key holders that are required to sign jointly may be included in the. certificate. In this fashion, the recipient 
is informed that any material which is signed by the authorityof the sender's certificate, must also be signed 

30 by a number of other specified signators. The recipient is therefore able to verify other joint and counter 
signatures by simply comparing the public keys present in each signature in the certificate. The present 
invention also includes other ways of indicating co-signature requirements such as by indicating other 
certificates. Such indications of other public key holders may be explicit (with a list as described here), or 
implicitiy, by specifying some other attribute or affiliation. This attribute or affiliation may also be indicated 

35 in each co-signer' certificate. 

Additionally, the present invention provides for the certification of digital signatures such that a trust 
level is.granted to the recipient for doing subcertifications. In this manner, a trust level of responsibility flows 
from a central trusted source. 

In an exemplary embodiment of the present invention, a certifier is permitted to assign with one 

40 predetermined digital code a trust level which indicates that the certifier warrants that the user named In tiie 
certificate is known to the certifier and is certified to use the associated public key. However, by virtue of 
this digital code, the user is not authorized to make any further identifications or certifications on Uie 
certifier's behalf. Alternatively, the certifier may issue a certificate having other digital codes including a 
code which indicates that tiie user of Uie public key is trusted to accurately identify other persons on the 

45 certifier's behalf and is further trusted to delegate this authority as the user sees fit. 

The present invention further provides for a user's public key to be certified in multiple ways (e.g., 
certificates by different certifiers). The present invention contemplates including the appropriate certificates • 
as part of a user's signed message. Such certificates include a certificate for the signer's certifier and for 
the certifiers' certifier, etc., up to a predetermined certificate which is trusted by ail parties involved. When 

50 this is done, each signed message unequivocally contains the ladder or hierarchy of certificates and the 
signatures indicating the sender's authority. A recipient of such a signed message can verify that authority 
such that business transactions can be immediately made based upon an analysis of the signed message 
together with the full hierarchy of certificates. 

55 

BRIEF DESCRIPTION OF THE DRAWINGS 
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These as well as other features of this invention will be better appreciated by reading the following 
description of the preferred embodiment of the present Invention taken in conjunction with the accompany- 
ing drawings of which 

FIGURE 1 is a exemplary block diagram of a cryptographic communications system in accordance 
with an exemplary embodiment of the present invention; 

FIGURE 2 is a flow diagram that indicates how a digital signature is created In accordance with an 
exemplary embodiment of the present invention: 

FIGURE 3 is a flow diagram that indicates how a digital signature created in accordance with FIGURE 

2 Is verified; 

RGURE 4 is a flow diagram that indicates how a countersignature is created for a digital signature; 
FIGURE 5 is a flow diagram that indicates how a digital certificate in created in accordance with an 
exemplary embodiment of the present invention; 

FIGURE 6 is a flow diagram that indicates how a joint signature is added to a certificate; and 
FIGURE 7 is a flow diagram that indicates how the signatures and certificates are verified by a 
76 recipient of the transmitted message. 
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DETAiLED DESCRIPTION OF THE PRESENTLY PREFERRED EMBODIMENT 

Rgure 1 shows in block diagram form an exemplary communications system which may be used in 
conjunction with the present invention. This system includes an. unsecured communication channel 12 over 
which communications between terminals A,B ... N may take place. Communication channel 12 may. for 
example, be a telephone line. Terminals A.B through N may. by way of example only, be IBM PC's having 
a processor (with main memory) 2 which is coupled to a conventional keyboard/CRT 4. Each terminal A.B 
through N also includes a conventional IBM PC communications board (not shown) which when coupled to 
a conventional modem 6. 8. 10, respectively, permits the terminals to transmit and receive messages. 

Each terminal is capable of generating a plain text or unenciphered message, transforming the message 
to an encoded, i.e., enciphered form, and transmitting the message to any of the other terminals connected 
to communications channel 12 (or to a communications network (not shown) which may be connected to 
communications channel 12). Additionally, each of the terminals A,B through N is capable of decrypting a 
received enciphered message to thereby generate a message in plain text form. 

Each of the terminal users (as discussed above with respect to public key systems) has a public 
encrypting key and an associated private secret decrypting key. In the public key cryptosystem shown in 
Rgure 1 each terminal user is aware of the general method by which the other terminal users encrypt a 
message. Additionally, each tenninal user is aware of the encryption key utilized by ttie terminal's 
encryption procedure to generate the enciphered message. 

Each terminal user, however, by revealing his encryption procedure and encryption key does not reveal 
his private decryption key which is necessary to decrypt the ciphered message and to create signatures. In 
this regard, it is simply not feasible to compute \he decryption key fi-om knowledge of the encryption key. 
Each terminal user, witii knowledge of anottier terminal's encryption key. can encrypt a private message for 
tfiat terminal user. Only tiie terminal end user with his secret decrypting key can decrypt \he transmitted 
fTi essaci 3 

Besides the capability of transmitting a private message, each terminal user likewise has the capability 
of digitally signing a transmitted message. A message may be digitally signed by a terminal user 
decrypting a message with his private decrypting key before transmitting the message. Upon receiving the 
message, the recipient can read the message by using the sender's public encryption key. In this fashion, 
the recipient can verify that only the holder of the secret decryption key could have created the message. 
Thus the recipient of the signed message has proof that the message originated from the sender. Further 
detail's of a digital signature methodology which may be used in conjunction with the present invention is 
disclosed in U.S. Patent t4o. 4.405.829. 

Before describing the details of the enhanced digital certification in accordance with the present 
invention, the general operation of Rgure 1 in an electronic mail, public key cryptographic context will 
initially be described. Initlally. presume that the user of terminal A is a relatively low level supervisor of a 
General iviotors computer automated design team who wishes to purchase a software package frorn a 
computer software distributor located in a different state. The computer software distributor has terminal N 
and an associated modem 10 located at his store. 
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The General Motors supervisor at terminal A constructs an electronic purchase order which identities 
the item(s) being ordered and the address to which the items must be sent as well as other items which are 
necessary in a standard purchase order. It should be recognized that, although this example relates to an 
electronic purchase order, any aggregation of data which can be represented in a manner suitable for 
5 processing with whatever public-key method is being used for signatures may likewise be transmitted. In 
the more detailed description which follows such an aggregation of data, e.g., a computer data file, will 
genericaily be referred to as an "object". 

The terminal A user, the General Motors supervisor, digitally signs the purchase order under the * 
authority of a certificate which is appended to the transmitted message which will be discussed further ^ 
70 below. Turning first to the supervisor's digital signature, a message can be "signed" by applying to at least 
a portion of the object being signed, the privately held signature key. By signing an image of the object (or 
a more compact version thereof known as a digest or hash of the object to be explained In more detail * 
below) with the secret key. it is possible for anyone with access to the public key to encrypt this result and 
compare it with the object (or a recomputed hash or digit version thereof). Because only the owner of the 
15 public key could have used the secret key to perform this operation, the owner of the public key is thereby 
confirmed to have signed the message. 

In accordance with the present invention, a digital signature is additionally accompanied by at least one 
valid certificate which specifies the identity of the signer and the authorization which the signer has been 
granted. The certificate may be viewed as a special object or message which specifies the identity of the 
20 user of a particular public key and the authority which has been granted to that user by a party having a 
higher level of authority than the user. 

To be valid a certificate must be signed by the private key(s) associated with one or more other valid 
certificates which are hereafter referred to as antecedents to that certificate. Each of these antecedent 
certificates must grant the signer the authority to create such a signature and/or to issue the purchase order 
25 in our example. Each of the antecedent certificates may in turn have its own antecedent(s). 

An exemplary embodiment of the present invention contemplates utilizing an ultimate antecedent 
certificate of ail certificates, which is a universally known and trusted authority, e.g., hypothetically the 
National Bureau of Standards, and which Is referred to as a meta-certificate. The meta certificate is the 
onlyitem that needs to be universally trusted and known. There may be several meta-certifiers, and it is 
30 possible that meta-certificates may even reference each other for required co-sighatures. 

Turning back to our example, when the message is ultimately transmitted from terminal A to the 
computer software distributor at terminal N. the recipient in a manner which will be described in detail 
below, verifies the signature of the General Motors supervisor. Additionally, he verifies that ail the other 
signatures on the message certificate and the antecedent certificates are present which provides further 
35 assurance to the terminal N software distributor that the transaction is a valid and completely authorized. As 
should be recognized, such assurances are critically important prior to shipping purchased items and are 
perhaps even more important in an electronic funds transfer context 

Any' party who receives a message transmitted by the user of terminal A (whether such a party Is the 
ultimate recipient of the message at terminal N or other parties within for example a corporate hierarchy 
40 such as General Motors) can verify and validate A's signature and the authority that the terminal A user 
exercised. Such validation is possible since a complete hierarchy of validating certificates is transmitted 
with the original purchase order which permits the ultimate recipient to feel confident that the requested 
transaction is authentic and properly authorized. 

Focussing more genericaily on major transactions emanating from, for example, General Motors 
45 Corporation, it is helpful to focus first on the ultimate certifier(s) mentioned above, i.e., the meta-certlfiers. In 
this regard, General Motors and parties who plan to do business with General Motors or otherwise 
participate in the public key cry ptosy stem may initially choose to approach a universally recognized trusted 
authority e.g., hypothetically the Bureau of Standards and/or one of the country's largest banks. Corporate 
and other participants in this system register a set of public keys (which they are authorized to use by 
50 virtue of an action of their corporate board of directors) with the meta-certifier. These are "high level" keys 
to be used within the General Motors environment primarily for certifying General Motors' internal 
personnel. The meta-certifier in return distributes to General Motors its certification that each of these 
supplied public keys created by General Motors is authorized for their own use. In effect, the meta-certifier 
is certifying that the party using each key is actually associated with General Motors. The meta-certifier's 
55 certification may include embedded text which indicates that the users of registered public keys are 
properly associated with General Motors. For example. General Motors may decide to have three "high 
level" keys certified, e.g.. corporate officers, such as the vice president, financial officer, and the security 
officer. At General Motors' request each of the three certificates indicate the public keys of the other two as 
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reauired joint signatures. , . . 

Thus once having obtained the highest level certiflcate{s) from the meta-certiner. several officials within 
General Motors may have to jointly sign certificates at the next lower level and such joint signatures. Each 
of these high level General Motors' certificates would mutually reference each other as required co-signers 
5 A this level no single corporate officer acting alone may authorize anything because embedded within each 
of the three certificates Is a requirement for the signature of others who are specifically identified. In turn 
then, these 3 officers create and sign public keys for the other General Motors' employees, that define 
exactly the level of authority, responsibility and limitations each employee is to have. One of these 
certificates may belong to user A. or will be an antecedent to user's A's certificate. 
10 Each of these three high level certificates may digitally sign terminal B user's certificate preferably after 
a face to face or telephone verification. After each of the required signatures has been created, the 
certificate's signatures by the vice president financial officer and security officer as well as their respective 
3 certificates, as well as those certificates' respective signatures by the meta-certifier are ultimately returned 
to the General Motors' supervisor at terminal B to be stored for ongoing use. such as in ou^example for 
,5 subcertlfying tennlnal user A. In this manner, the signed message unequivocally contains the ladder or 
hierarchy of certificates and signatures verifying terminal A user's identify and his authorrty. 

When a party B in a ladder of certifications creates an authorizing certificate for party A. the certificate 
includes a specification of A's Identity together with A's public encryption key. Additionally, the certificate 
Indicates the authority, capabilities and limitations which 8 wishes to grant A. By granting this certificate B 
20 explicitly assumes responsibility for both A's identity and authonty. 

B's cerfificate for A also permits a specification of other parties who are required to cosign actions 
taken by A when using this certificate as will be explained further below. Cosignatures may take the form of 
either joint signatures or countersignatures. Additionally party B can define in the certificate for A- the 
degree to which B will recognize subcertifications performed by A. „,«„»«h 
2S in accordance with an exemplary embodiment of the present mventon. tmj levels which are gramed 
by ttie certifier to the certifiee are specified In the certificate by a predetermined digital code. Such a trust 
level is used by the recipient of the message as an indicator of the authority granted to the certifiee and ttie 
• responsibility assumed by the certifier for the certifiee's actions with respect to the use of tiie public key 
being certfi^. ^ ^^^^^ indicated by trust level values 0. 1 . 2 and 3 - 

Tmst level 0 indicates that the certifier vouches that ttie certified public key belongs to the individual 
named in ttie certificate: but that the certifier will not assume responsibility to"- J^e accura^ of _any 
certificates produced by the certifiee. The essence of this would be a statement by the certifier ti^at. I 
w^*e n^ed in this certificate is known to me and is being certified to use tfie associated public 
35 kev -however I do not trust him to make any further indentifications on my behalf . 

Tnist level 1 empowers the certifiee to make level 0 certifications on behalf of tiie certifier. The essence 
of this would be a statement by the certifier ttiat: "I know the user of this public key and ' W-^^; ^ 
accurltS Identify other persons on my behalf. I will take responsibility for such identiflcatio^. However I 
ro1^S?uil,n^^^^ t^ldentify persons as trustworthy." Trust ^ J-Powjsthe "^f^ o 
40 level 0 1 and 2 certifications on behalf of the certifier. The essence of this would be a statement by the 
ceiSie; i,rf-l lS,w the user of this public key and I trust him/her to accurately Identify other Persons on 
mv behSf and I furthemiore trust ttiem to delegate tills auttiority as ttiey see fit. I assume due 
responsibility for any certifications done by them or any duly authorized agent created by ttiem or by otiier 

''''^XT^S':f:^T^L^eS, for an u.mate meta certifier whose public key cei.ficaje is 
established and also well known (possibly by repetitive and widespread media P"b'teat.«^n) ^.^j^^^^ 
accuracy is universally respected. This certifier takes responsibility only for accurately identifying me 
entities whose public keys it certifies. It assumes no responsibility for ttie use of ttiese keys. 

^ditionally each certification may specify ttie monetary limit. I.e.. ttie maximum amount of money 
value which ttie certifiee is autiiorized to deal witfi. The monetanr limit must not of course ^^^'^^^^''^^ 
me certifier's own certificate to insure ttiat tiie certifier does not delegate more tiian he .s allowed to 

Store discussing further details of ttie digital signature and oertifl^^lon techniques of the present 
invention it may be helpful to first define certain terminology. As noted above, the term object is 
aeneSly u^ed to describe any aggregation of data tiiat can be ultimately represented in a manner 
Slelor pr^e sing witi. whatever public key method is being utilized for signatures and/or encojption 
The tem> object may apply to a "primary- object such as a purchase order or check, or money transfer, or 
to a "secondary" object such as a certificate, or anottier signattjre. 
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The methodology of the present invention in order to increase processing efficiency generally applies a 
function to the object to create a generally smaller, more compact, more easily processed object, i.e., 
typically a fixed size bit string of several dozen or more bits. Such a function is referred to as a hash or 
digest of the object 

An example of such a hash or digest would be the output obtained by processing an image of the 
object with the data encryption standard (DES) using cipher block chaining mode (CBC). Processing may 
be done with two different DES keys (both of which are fixed, non-secret and commonly known). Thereafter, 
each of the final output chaining values are concatenated or merged in some way to become the several 
dozen or more brts constituting the digest or hash value. 

An important characteristic of the digest or hashing algorithm is that, while it is easy to compute the 
digest of an object it is essentially impossible to construct a different or modified object with an equal 
digest For all practical purposes the digest is an unforgeable unique fingerprint of the original object If the 
original object Is changed In any manner, the digest will be different. In other words, for ail practical 
purposes, the more compact representation of the original object is unique to the original object Ideally, 
also a hash should not reveal any clue about specific data values contained within the message. The hash's 
contemplated in the exemplary embodiment have at least 128 bits. 

Turning now to Rgure 2, this figure shows the data flow and the manner in which signatures are 
created. The signature process applies not only to general objects such as arbitrary computer files, letters, 
electronic purchase orders, etc., but also to specialized objects such as signatures and certificates. 

Each digital signature is accompanied, as is generally shown in Rgure 2, by a certification of the public 
key performing the signature. The certificate, as will be discussed in detail in conjunction with Rgure 5, is 
signed by one or more higher authorities (i.e., the immediate certifiers) and identifies the original signer 
while specifying the degree of authority which has been granted to the original signer. 

In accordance with the present invention, the original signer may have more than one certificate and 
may utilize different certificates for different levels of authority. Each of the certificates may carry different 
limitations and requirements including different money limitations, trust levels, joint signature requirements 
and counter signature requirements. 

It is incumbent on the signer to select the appropriate signature/certificate with which to sign a particular 
object For example, purchase orders may require a different type of authority (and therefore a different 
certificate) than merely a letter of inquiry. Thus, the certificate Is a very important portion of the transmitted 
message in that it identifies the signer as well as the signer's level of authority. 

As shown in Rgure 2. in creating the signature the user utilizes the object 20 (which may. for example, 
be a purchase order) and specifies the type of object 22. The documentation added under the type of 
object field, for example, indicates that the object is a purchase order data file. In other instances the type 
of object field 22 would identify that the object is another signature or a certificate. As indicated at 24. the 
date of the signature is also identified. 

The comment field 26 is utilized to add documentation which, for example, places limitations on the 
signature or adds other commentary. The signer may indicate that his signature or the object is only good 
and valid for a predetermined period of time. Additionally, any desired comments regarding the particular 
transaction, e.g., the purchase order, may be added as comment data. 

Also incorporated in the signature is the original signer's certificate 28 which includes the original 
signer's public key 30 and numerous other fields which are discussed in detail below in conjunction with 
Figure 5. As noted above, public key signature methods require the use of a public key 30 and an 
associated private key which is shown in Rgure 2 at 32. 

The object field 20 (e.g., purchase order data), the type of object field 22, the signing date field 24. the 
comment field 26, and the signer's certificate field 28 are hashed via a hashing algorithm at 34 to enhance 
processing efficiency. Additionally, each of the fields 20, 22. 24. 26 and 28 are incorporated in the signature 
packet 42 to become part of the signature record, A hashing algorithm 44 is also applied to the object 20 to 
place it in a more compact form prior to incorporation in the packet 42. 

After application of the hashing algorithm 34 to the fields previously discussed, a presignature hash 
results therefrom as indicated at 36. The presignature hash 36 is then run through a decrypt (signature) 
cycle as indicated at 38 using the signer's private key 32 to thereby result in the signer's signature 40. The 
signer's signature 40 together with items 20 (or the hash of 20), 22. 24. 26 and 28 become the final 
signature packet 42. 

When this signature is transmitted with the associated object, it allows the recipient to verify that the 
object is intact as it was signed. Furthermore, when sufficient certificates are also included, the recipient 
can validate the true identity of the signer and the authority which has been granted in the signer's chain of 
certificates. 
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Turning now to Figure 3. this figure shows how a recipient of the transmitted message, including the 
sianature packet 42 constructed in accordance with Rgure 2. verifies the signature. As shown in Rgure 3. 
the recipient utilizes the signature packet 42 and the associated fields 22. 24. 26 and 28 as well as the 
object 20 and applies the same hashing algorithm 34 as applied to these same fields m Rgure 2 to thereby 

s result In a preslgnatojre hash 50. . , ^ . oa ^ 

The recipient then utilizes the pubfic encrypting key transmitted with the signers certificate 28 and 
performs an encrypt (verification) operation 52 on the signature to be verified 40 (which was transmitted 
JJth the signature packet) to thereby generate a presignature hash 54. The recipient, by recomputing the 
presignature hash in the same way as the signer, then compares this value with the encrypton (venfication) 

TO of the signer's signature. . ,' ^ » 

As Indicated at block 56. if these two values at SO and 54 are not equal, the recipient cannot accept the 
received siqnature as being valid. Whether intentional or otherwise, the object and/or the signature must 
have been changed or tampered with in some way since they were signed. By virtue of this verification 
step the recipient determines that the digital signal is consistent with the public key that was named. 

,5 in this manner, the object and its signature are processed to insure that the object is identical to the 
data which existed as it was signed by the owner of the public key. This is the first step of an overall 

validdtion process. . . . 

other steps in the validation process insure that the public key belongs to the person named in the 
associated certificate and that the person has the authority stipulated in the certificate. This venfication 
20 process applies generally to any object even if that object is another signature or a certificate. To comp ete 
the valldaflon process, the recipient analyzes the certificates associated with the signature to determine tha^ 
the proper authority has been conveyed to each certificate through its signatures and the antecedent 

certHlcate(s) of these authorizing signatures. . „ . ^ .u ^*^^r.. 

An object may be accompanied by more than one signature. Such cosignatures fall into the categonr of 
either a joint signature or a counter signature. A joint signature is simply another signature of an object by a 
different party. The signature process is no different than that used to create the initial signature as 

described in conjunction with Rgure 2. ..... -.^^u 

A counter signature is a signature of a signature. Thus, when A signs an object this signature may .tself 
be thought of as an object. Thus, when C countersigns A's signature, the object C is signing is As 
30 signature itself rather than the original object The counter signature must therefore^ occur after the signature 
bSng countersigned and reflects approval (or at least recognition) of both the underlying object asjve ' as 
the fact that A has signed that object This mechanism allows a chain of authority where each higher evel 
approves any commitment made at a lower level. One of the unique aspects of this system Is that the 
certificate A associates with this signature may in fact require that the use of A's signature be accompanied 
35 by particular other joint or counter signatures. ^ . „ « <w a 

Turning next to the creation of a counter signature which is shown in Rgure 4. initially A signs at Kl a 
Drimary object 60 in accordance with the procedure outlined in detail in conjunction witti Rgure 2. The 
primary object 60 may be a purchase order or some otiier commitment or tt may be a counter signature of 
some ottier signature of a primary object , : « 

AS explained above in regard to Rgure 2. Uie process of A signing an object may also involve some 
other paZ signing A's signature. Thus. A's certificate 62 specifically defines at 65 that m order for A s 
sSnatJrl to be vL (i.e. ratified), a counter signature by C is required, for example, using C's specific 

"'*Afte?A signs tiie object. A's signature packet 68 is Oien forwarded along witti ttie primary object and alt 
45 assocSed stonatu^^es a^d certificates to C and A requests that C add his counter signature 64. Upon 
^eiC the r^aterial. C reviews aU existing signature certificates and ttie primary object and ,f everything 
rSe s with hiT approval he would decide to sign A's signature 68. A's signature inherentiy reflects *e 
primiy Object and C's signature inherentiy reflects A's signature so 0 will essentially have "signed on the 

so Onc^C icSesTapprove A's signature at 68. ttie process of creating a signature as shown J detail in 
Rgure 2. is duplicated except Uiat tiie object is A's signature. Thus, witin A's ^'9"^"™/%*^ °^J^!' j^,^, 
ttie type of object being designated as a signature at 72). ttie counter signatiire date 74 Cs counter 
SnlTe comment 76. L C's certificate 70 are applied to a hashing algoritiim 80 to ^^^^f y^f"" "^^ 
preslgnahire hash 82. At the same time, these fields are also inserted Into the counter signature Packet 88 

55 as discussed above with respect to the signatore packet 42 (with a hashing algontiim 69 being applied to 

P?e"staIIat^rThash 82 and C's secret key 92 are applied in a signature operation 84 to generate a 
counter signature 86. This counter signature becomes part of the counter signature packet 88 m precisely 
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the same fashion as described previously in regard to the creation of signature packet 42 in Rgure 2. 

Because the certificate "Y" which C must use to perform the signature has been explicitly stated (in the 

certificate which A used to sign), C may also be required to meet his own cosignature obligations so 

specified by "Y" and forward this entire package including his own newly added signature on to other 
5 parties for further cosignatures (either joint or counter signatures). This recursive signature gathering 

process continues until sufficient signatures are added to fully satisfy all cosignature requirements of at 

least one party who initially signed the primary object 

Turning next to how one party creates an authorizing certificate for another, it is noted that B creates an 

authorizing certificate for A by combining a specification of A's identity together with the public encrypting 
70 key which A generated for himself. Additionally 8 specifies the authority capabilities and limitations which B 

wishes to grant A. By signing the certificate B explicitly assumes responsibility for A's identity and authority. 
The present invention permits B to specify other signators who are required to cosign actions taken by 

A when using the certification. As noted above, B can further define in the certificate for A the degree to 

which 8 will recognize subcertifications performed by A. 
15 Additionally, many other limitations and restrictions may be imposed by B. For example. B may impose 

a money limit which will insure that any recipient of A's certificate will be aware of the limit B is willing to 

authorize. Since the process of creating a certificate, as will be shown below involves signatures, the use of 

cosignatures is extended to permit certification authorization. For example, certificates may be designed to 

allow delegation of subcertiflcation, but only if particular multiple cosigners are involved. This allows checks 
20 and balances to be structured into a hierarchy of authority so that electronic digital signatures can be used 

across organization and institutional boundaries with great confidence -both by the parties receiving the 

signatures and the parties granting the authority to use the signatures. 

The manner in which a party B creates a certificate for party A is shown in Figure 5. As indicated at 

100« A creates a public/private key pair in accordance with conventional public key signature systems and 
25 supplies the public key to B 102. Once B obtains the public key provided by A for certification, it is 

important for B to insure that the public key is actually one generated by A and not someone masquerading 

as A. In this regard, it may be desirable for the public key generated by A to be provided on a face to face 

basis. 

Having selected his own certificate with which to sign A's certificate. B at 106 utilizes the certificate 108 
30 with the associated public key 110 to create a signature of a new certificate 112. As .in Rgure 2. the 
signature is created using an object (A's certificate 116) and a certificate (B's certificate 108). B's secret 
private key is utilized in the decrypt operation to create the signature 112 of the new certificate 116 and the 
signature packet 114 of B's signature becomes part of A's new certificate packet. 

Focussing on the certificate for A which is constructed using information about A specified by B, B 
35 builds tiie certificate by utilizing tiie public aspect of A's public key as provided by A via line 103. B also 
sets forth A's full name, A's title and otiier important statistics such as his address, and telephone number. 
B may also include a comment to go with the certification which will be available to any person In the future 
who needs to examine A's certificate. 

B additionally will indicate an expiration date of the certificate. This date may reflect the date after 
40 which A should not use the certificate. Alternatively, the date may call for any certificate created by A to 
also expire on this date. B may also indicate in the certificate an account number for A which may 
represent an internal identification code within B's organization. 

Additionally. B may place a monetary limit in the certificate. This monetary authority or credit limit is 
checked against the limit in B's own certificate to insure that B does not delegate more tiian he is 
45 empowered to delegate. This same relationship is also verified by future recipients as part of tiieir validation 
process. 

As discussed above, B also defines tiie degree of responsibility to which B is willing is assume for 
subcertifications done by A. This field must be compatible witii the trust level which is allowed B's own 
certificate. The relationship between the trust level granted to B and that granted by B is anotiier of the 
50 relationships validated whenever future recipients validate the hierarchy of certificates which are presented 
to them. 

Finally B inserts cosignature requirements into A's certificate which specify how many and what type of 
cosignatures are required to accompany A's signature when A uses this new certificate. As indicated above, 
cosignatures may be in the fonn of joint signatures and/or counter signatures. The counter signature 
55 indicates an approval of the use of the certificate and the approval necessarily follows the associated 
signature. Joint signatures can be done in any order and do not necessarily reflect approval of the other 
signatures, but simply approval (or recognition) of a common object. 

Cosignature requirements may, for example, be specified in the certificate in a variety of ways. One 
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technique which may be used is to explicitly define a list of valid joint signers and a list of valid counter 
signers Associated with each list is the number specifying the minimum associated signatures which must 
be present in order for a recipient to recognize the signature as being fully approved. The joint signature list 
may be a vector of hash values of each of the set of other public keys. Some specified minimum number of 
these keys must appear in certificates of other signatures applied to any object signed by A when using this 
new certificate. Otherwise any recipient should not treat A's signature as valid. 

The counter signature list is a vector of hash values of other certificates which must be used to sign 
any signature made under the authority of this certificate. Since this references certificates (rather than 
pubfic keys) it Is possible to reference specific certificates which themselves need further joint or counter 
signing By selecting appropriate certificates to appear here, it Is possible to create hierarchy of counter 
signature requirements to whatever a level an organization feels comfortable. A specified number of 
cosigners Is required from each category. This can range from all the candidates to some subset, for 
example, 0, 1, 2 or 3. ,. ,„ . 

The set of possible co-signers may be indicated explidty in a list as described here, or implicitly by 
specifying some quality or attribute specification which Is designated in each possible co-signer's certif- 
icatG 

other fields may be included in the certificate. For example, the current date and time which reflects 
the moment of the initial creation of the certificate. As indicated in Figure 5. the complete certificate 
consists of a certificate packet with includes the certificate 116 for A and the signature packet 114 of Bs 

signature to A's certificate. . ^ a * 

B's signature and the hierarchy of all certificates and signatures which validate it are kept by A and sent 
along whenever A uses his certificate. It is contemplated that 8 or other parties may create several 
certificates for A. For example, one certificate might allow A to refiably identify himself with no further 
designated authority. Another certificate might allow authorization to A of certain limited money amounts 
without requiring any cosignatures. A third might allpw authorization for larger amounts but require one or 
more cosignatures. Still another might allow A to subcertify other persons according to still different money 
and/or authority limitations and/ or co-signature specifications. 

Assuming that B has created a certificate for A as shown In Rgure 5, if 8 requires no cosigners then 
the certificate is complete. However, the certificate which empowered B to create A's certificate may have 
required that B have cosigners. There may be one or more joint signature and/or counter signature 

^^"ngurre exemplifies the steps taken by party C to jointly certify the certificate of A. The requirement to 
have a joint signer would be specified in B's own certificate. In this case, a transmitted object (in this case 
A's new certificate) signed with B's certificate would be rejected by a recipient if C's joint signature is not 

also present on the object. . , . • o 

As shown in Rgure 6. if such a joint signature is required, a copy of B's certificate for A is sent to C 
who must jointly sign the certificate 120. C then examines A's certificate 122 and verifies that *ie pubHc key 
of the certificate actually belongs to A In accordance with process outlined in conjunction with Rgure 3. 

C then examines the signed attributes and authorizations set forth in the certificate including the 
assigned monetary level, trust level, etc.. C then, upon concluding that all the fields in B's certificate for A 
are Appropriate, selects his own certificate with which to perfomi the signature 126. With his own certificate 
128 C signs B's certificate of A 132 (130). Once C signs his certificate his signature appe^s essentally 
par^lel with B's signature and any other cosigners as shown at 134 and 136 of figure 6. Thus, it is 
Important that C exercise as much caution as B when approving A's certificate. Once As certificate is 
created no cosigner may change the certificate for to do so would create essentially a different object to 
which none of the previous signatures would apply. If C does not approve the certificate he must avoid 
Signing it. and should have a different certificate constructed and re-signed by all necessary Pfrt'es. After C 
adds his joint certificate to B's certificate of A. A's certificate packet consists of the certificate for A 132, B s 
signature packet for A's certificate 1 34 and finally C's signature packet for A's certificate 1 36. 

In regard to C's signature packet it is noted that, in order for C to validly sign the certificate, he must 
select one of his own certificates which grants him sufficient authority to cover what is specified in the new 
certificate for A. If C has no such certificate, then it Is impossible for him to validly sign the certificate since 
future recipients would reject his certificate as having Insufficient authority. 

it is noted that C's certificate may also require a counter signature by another party. If so. C forwards 
the certificate and ail associated signatures to the specified party, e.g.. 0. to counter sign C's signatojre. 
When 0 receives the material he performs the same verification steps as C on the new certificate, if he 
approves then O adds his signature to the set. However. D signs C's signature rather then the original 
certificate object That is. the object of D's signature is not the object of C's signature (which in this case 
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was the certificate for A) but rather the object is C's signature rtsetf. This counter signature therefore differs 
from the joint signature which is simply another signature of the same object 

The application of joint and/or counter signatures can be nested to whatever depth is required. Thus, if 
D is required to have joint signatures, then this package should be passed to one of D's candidate joint 
signers for approval of C's signature. This would be a joint counter signature. Similarly, in organizational 
hierarchies it Is possible that D might require counter signatures in which case someone else will need to 
sign D's signature. 

As explained above, the recipient of a primary object (such as a purchase order) and its associated 
signatures, processes the received materials to insure that the object is Identical to the material which 
existed as it was signed by the owner of tiie public key. The process for verifying the signature and for 
verifying that the object had not been tampered with has been explained above in regard to Rgure 3. 

Additionally, the recipient needs to verify that the identity of the signer is correct and further that the 
signer has the proper authority within his organization to make the commitments implied by the received 
object The sender of the object (e.g.. the purchase order) has the responsibility of sending all generations 
of antecedent certificates and signatures (up to and including the meta-certificate) which are needed for a 
recipient to perform validation operations. 

In validating the object and its signatures, tiie recipient may. for example proceed as follows. Rrst tiie 
recipient insures that the primary object 150 has at least one signature. In the example shown in Figure 7, 
the primary object 150 has four associated joint signatures 152, 168. 180 and 200, each of which has 
associated certificates 154, 170, 182 and 202 respectively. 

Certificate 154 was made requiring joint signatures by tiie owners of certificates 170, 182 and 202, and 
counter-signatures by the owners of certificates 162 and 166 using these specific certificates. The certificate 
154 itself was autiiorized by the owner of certificate 158 as evidenced by signature 156. 

In tills example, tfie owner of 154 has obtained tiie necessary counter signatures 160 and 164 by tiie 
holders of certificates 162 and 166, as well as ttie necessary joint-signatures 168, 180 and 200. 

To provide validation for his signature 168, tiie owner of certificate 170 must include the authorization 
for his certificate. His certificate was signed by tiie holder of certificate 174 (as evidenced by 172). however 
174's certificate specified tiiat a joint signature by tiie owner of 178 was required in order to fully ratify 
I74's signature 172. Thus signature 176 which was made sometime in the past fulfilled all of I74's joint 
signature requirements and thereby validated (ratified) the use of 170. 

Looking at joint signature 180, by tiie owner of 182, we learn that 182 requires counter signatures by 
the holder of 186 using tiie specific certificate 186. The holder of 182, did in fact get the counter-signature 
184 by the holder of 186. However, certificate 186 requires that any signature by 186 itself be countersig- 
ned by ttie holders of certificates 190 and 194 (using these respective certificates). These two holders have 
in fact countersigned 184 as evidenced by 188 and 192. At one further level we ieam tiiat certificate 194 
requires any signature by 194 be counter signed by tiie holder of certificate 198. which signature 196 has 
been obtained. Certificate 202 requires no co-signature. 

All certificates must be accompanied by signatures which are themselves autiiorized by antecedent 
certificates. Ultimately all the autiiority can be tiraced to a set of certificates which have been signed by ttie 
holder of the meta-certificate (or possibly a small set of meta-certificates). Each meta-certificate is well 
known and distributed to all parties "throughout the world-. 

The recipient examines every signature supplied and verifies that each accurately signs its purported 
object (whether tiie object is a primary object, a certificate, or another signature) using tiie procedure 
detailed in Rgure 3. The recipient insures tiiat each signature includes a corresponding validated certificate. 

If a certificate requires joint signatures, tiien the recipient insures that tiie required number of tiiese 
necessary signatures (to tfie same object) are present. If the certificate requires counter signatures, then the 
recipient insures tiiat tiie required number from tiie designated subset are present (the counter signatures 
have signatures as ttieir object). 

All certificates are tiien examined. A check is made for the special meta-certificate which has no 
signature but which is universally known and trusted and a copy of which is already stored in the recipient's 
computer. If a certificate is received which claims to be tiie meta-certificate but which is not equal to that 
already known to and accepted by the recipient, tiien a rejection is issued. If the meta-certificate is properly 
recognized, then the validation process continues. 

Additionally, a check is made to insure that any other certificate besides ttie meta-certificate has at least 
one signature. As noted above, a check is made to insure that ail necessary cosignatures for all presented 
objects are present. Additionally, a check is made to determine that antecedent certificates grant sufficient 
authority to the subcertlficate signers to permit them to validly sign the certificate. 
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In this regard, the trust value in the certificate must be consistent with the antecedent i.e.. the certificate 
of its signers). By way of example only, the following trust field combinations are valid (using the example 
specified earlier). 
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Additionally, any monetary limitations set forth in the certificate must be observed. The money limit 
allowed by a certificate must not exceed its antecedent Additipnally a checit should be made to insure that 
th© antecedent's expiration date is compatible with the antecedent's expiration date. By way of example 
only a check may be made to insure that the expiration date in every certificate exceeds the date of each 
signature which relies on It In some cases, it may be desirable to reject any material which is controlled by 
an obsolete certificate. 

In order to detect "closed" authority loops (by which a series of certificates may be structured in a loop 
with the last member of the loop granting authority to the first), it is necessary to insure that ail authority 
ultimately flows from recognized meta-certlficates. in this manner, a chain of false or artificial certificates 
which mutually certify each oflier will not be inadvertently allowed to incorrectly pass the validation process. 

One way to accomplish this is to check off certificates in a series of iterations, starting at the top with 
the meta-certificate. At each iteration, ceiUflcates are scanned and in the process certificates having at least 
one checl<ed off antecedent would in turn be checked off. The iteration stops when no new certificates have 
been checked off. If any certificates have not been checked off. then these are "orphans" which should 
never have been supplied. Such a transmitted package would be rejected. 

Once the signatures and certificates are validated (based on the ultimate authority of th© meta- 
certificate(s)) the final step Is to insure that the commitment inherent in the primary object is within the 
authority granted to its immediate Ooint) signers. This is done by considering the value imputed to the 
primary object with the certificates of its signers. 

Although the use of a meta-certifler insures that ail authority ultimately flows from a trusted source and 
provides protection, the present invention is not limited to a certification methodology which necessaniy 
includes a single meta-certifier. On the other hand, it is contemplated by the present invention to allow for 
the use of multiple meta-certiflers. These shouW be certificates governed by entirely independent sources 
possibly reflecting the apex of enfirely different authorizing hierarchies (e.g.. the govemmental sector versus 

the private sector). ■ .„ ^ _.,„ v.!i 

Another use of multiple meta-certifiers could be to avoid concentrating full meta-certiflcadon responsibil- 
ity wiUi one group. For example, it might be uncomfortable to know that there is a single entity which could 
in theory create forgeries on behalf of anyone else by creating false certificates. This concern may be 
alleviated if the meta-certification authority were distributed among different trusted meta-certifiers. Each 
meta-certifier would operate completely independently but each certificate would specifically require the 
others as joint signers. This would essentially eliminate ttie possibility ttiat isolated corruption within a smg e 
organization would compromise the system. For example, any organization that wished to be certified would 
need to have their own high level master certificate corroborated by each separate entity. Large organiza- 
tions may likewise wish to structure tiieir own master certificates to be constructed so as to require joint 
signatures in order to provide multiple safeguards against the danger of isolated corruption witiiin ttie 

°^^^Whnrthe invention has been described in connection with what is presently considered to be the most 
practical and preferred embodiment, it is to be understood that the invention is not to be limited to me 
disclosed embodiment but on the contrary, is intended to cover various modifications and equivalent 
arrangements included wittiin the spirit and scope of the appended claims. 
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Claims 

1 . In a communications system having a plurality of terminal devices (Terminals A to N) coupled to an 
insecure communications channel (12) over which users of said terminal devices may exchange private 

5 messages, each of said user's having a public key (30) and an associated private key (32). an improved 
method of digitally signing and certifying a message to be transmitted characterized by the steps of: 
formulating at least a portion of a digital message (20); 
digitally signing said message (40); and 

including within said message an authorizing certificate (28. 116) which specifies the authority which has 
70 been granted to the signer of said message. 

2. A method according to claim 1» further including the step of providing at least one field in said 
message identifying the nature of the digital data being transmitted (22). 

3. A method according to claim 1 , wherein the fomnulating step includes the step of providing a field 
allowing the user to insert a predetermined comment (26) regarding the data being transmitted. 

75 4. A method according to claim 1. further including the step of applying a hashing function (34) to at 
least a portion of the message to be transmitted to form a preslgnature hash (36); and wherein said digitally 
signing step includes the step of decrypting said preslgnature hash with said private decrypting key (32) to 
form said digital signature. 

5. A method according to claim 4. further including the step of forming a digital signature packet (42) 
20 comprising the digital signature and a representation of said at least a portion of the message to be 

transmitted. 

6. A method according to claim 1. wherein said authorizing certificate (116) defines the cosignature 
requirements which must accompany the signer's signature. 

7. A method according to claim 6. wherein a digital signature by a third party indicating approval of the 
25 user's signature is required (116) thereby defining a counter signature requirement 

8. A method according to claim 7. wherein the third party countersigns (86) by digitally signing the 
sender's digital signature. 

9. A method according to claim 6, wherein the step of defining cosignature requirements includes the 
step of specifying at least one other digital signature which is required to appear in the digital message 

30 thereby defining a joint signature requirement (1 1 6). 

10. A method according to claim 1, wherein said authorizing certificate defines limitations as to the 
authority granted by the certificate (116). 

11. A method according to claim 10, further including the step of setting a monetary limit for the sender. 

12. A method according to claim 1, wherein said authorizing certificate includes at least one field 
35 indicative of the degree of responsibility delegated to the sender. 

13. A method according to claim 1, wherein said authorizing certificate defines a hierarchy of 
certificates within the transmitted message such that a recipient of the message can verify the authority of 
the signer based upon an analysis of the signed message. 
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@ A public key cryptographic system Is disclosed 
with enhanced digital signature certification which 
authenticates the identity of the public key holder. A 
hierarchy of nested certifications and signatures are 
employed which indicate the authority and respon- 
sibility levels of the individual whose signature is 
being certified. The present invention enhances the 
capabilities of public key cryptography so that it may 
be employed in a wider variety of business transac- 
tions, even those where two parties may be virtually 
unknown to each other. Counter-signature and joint- 
signature requirements are referenced in each digital 
certification to permit business transactions to take 
place electronically, which heretofore often only 
would take place after at least one party physically 
winds his way through a corporate bureaucracy. The 
certifier in constructing a certificate generates a spe- 
cial message that includes fields identifying the pub- 
lic key which is being certified, and the name of the 
certifiee. In addition, the certificate constructed by 
the certifier includes the authority which is being 
granted including information which reflects issues of 
concern to the certifier such as, for example, the 
monetary limit for the certifiee and the level of trust 
which is granted to the certifiee. The certificate may 
also specify cosignature requirements which are be- 
ing imposed upon the certifiee. 
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